走到第 30 天，這個專案的 MVP 已經完成。最後一篇，我想用 MVP 的角度回頭看：這個專案做了什麼、刻意沒做什麼，再來聊聊「如果還想延伸，可以往哪些方向發展」。這些是我做完之後的發想，有些我評估過、有些只是想法，我會盡量誠實標明哪些是做過的、哪些是讀來的。

🧱 地基概念

MVP（Minimum Viable Product，最小可行產品）

MVP 不是「半成品」，也不是「做得很爛的版本」，而是刻意只做最重要的部分，但整條流程要能從頭跑到尾。比喻：想開一間餐廳，不是先把裝潢、外送、會員制度全部做好，而是先用一張桌子、三道菜開張，確認真的有人來吃，再決定要往哪裡擴充。

MVP 有兩個關鍵：

• 範圍要刻意收斂：寫下「這次不做什麼」，跟寫下「要做什麼」一樣重要。
• 要有明確的成功標準：知道什麼狀態叫做完成，才不會一直加功能。

技術債：為了先做出來，刻意留下、之後要還的取捨

技術債不一定是壞事。只要是「知道它存在、也評估過代價」的取捨，就是一種誠實的選擇。真正的問題是不知道它存在。

🔧 從 MVP 的角度，看這個專案做了什麼

成功標準： 使用者輸入 → 前端 → API → 程式算營養 → AI 理解並生成菜單 → 前端顯示 → 公開網址可以操作。

MVP背後的取捨讓我能在有限時間內先把整條路走通，代價是這個專案目前功能單一，沒有其他更進階的功能，例如每日追蹤、也沒有真正的 API 防護，這些在前面幾篇（尤其 Day28）都已經記錄過。

還可以延伸哪些功能？

MVP 做完不代表每個功能都要補，而是看「現在最痛的問題在哪」，再決定往哪個方向長。我把可能的延伸分成五個方向：

延伸一：讓輸入更準，進階引導式問診

目前使用者在一個大輸入框裡自由描述飲食，是單次輸入，AI 沒辦法追問。自由文字門檻低，但容易寫得籠統、漏掉細節。

我的想法是：保留自由文字當預設，另外加一個「進階功能」入口，點進去後改成一題一題引導，參考營養師常用的「24 小時飲食回憶錄」問診邏輯，問出吃什麼、什麼時候吃、大約多少份量。

為什麼不直接取代原本的設計？因為強制所有人都走問答流程，會拉高使用門檻、拖慢速度，而且如果要花太多時間填寫會降低使用意願，所以定位成「選用的進階功能」。至於要問哪些問題、順序怎麼排，就可以參考營養師的問診經驗來設計。

延伸二：持續互動，串 LINE Bot

網頁版目前是一次性產生建議，沒有登入、也沒有歷史紀錄。我想過的做法是：使用者在網頁確定飲食方向後，可以透過 LINE 每天記錄吃了什麼，AI 依據當初建立的飲食型態給回饋和鼓勵。LINE 是台灣使用者很熟悉的介面。

但要做每日追蹤，勢必得面對兩件事：怎麼辨識使用者，以及資料存哪裡，也就是登入和資料庫。這兩件事正是 MVP 刻意排除的，所以這個延伸比較像是「下一個階段」，不是小加功能。

延伸三：資料更廣、更準，資料庫結合 RAG

這是我最想多聊的一個延伸，因為它跟這個專案的核心最有關。

先搞清楚：什麼是 RAG？

RAG（檢索增強生成）的白話意思是：不要讓 AI 憑記憶回答，而是先去資料庫「查」出相關內容，再把查到的真實資料交給 AI 參考。它有三步：檢索（去資料來源查）、增強（把查到的資料放進 prompt）、生成（AI 依據資料回答）。

檢索的方式不只一種：

• 結構化比對：資料欄位固定（例如食物有名稱、熱量、分類），用欄位條件直接篩選。簡單、便宜、可預測。
• 語意向量檢索：資料是大量的非結構化文字（例如一本 PDF 手冊），先轉成向量，再找語意最接近的段落，就算用詞沒完全對上也找得到。需要 embedding 和向量資料庫。

這個專案現在怎麼做： 其實已經是 RAG。生成菜單前，程式先從約 1900 筆食物資料裡，用 mealSlot、cuisineStyle、熱量預算這些結構化欄位篩選出候選食物，把候選清單放進 prompt 讓 AI 挑，份數再由程式計算。資料放在 S3 的 JSON 檔，Lambda 讀進來後篩選（見 Day21 到 Day24）。這是「結構化比對」的檢索。

那 AWS 上有沒有更適合的做法？ 有，而且選項不少。以下是我查官方資料整理的，我還沒有實際用過這些方案：

Bedrock Knowledge Bases 可以搭配的向量資料庫，官方列出的包括 Amazon Aurora（PostgreSQL 的 pgvector）、Amazon OpenSearch（Serverless 或 Managed Cluster）、Neptune Analytics，以及第三方的 MongoDB、Pinecone、Redis 等。另外，Amazon S3 Vectors 在 2025 年 12 月正式上線，可以把向量直接存在 S3，並且能當 Knowledge Bases 的向量儲存。AWS 宣稱它能大幅降低成本，實際費用請以定價頁為準。

我的判斷： 以這個專案現在的規模，食物資料只有約 1900 筆、欄位固定，又需要「AI 不算營養」的確定性，現在的做法已經是合理的 RAG，不必為了「用 AWS 託管服務」而換。真正會讓我考慮換的，是這兩種情境：

1. 想讓 AI 讀官方 PDF 手冊（食物代換表、每日飲食指南），引用原文的數字和措辭。這是非結構化文字，用 Knowledge Bases 加向量資料庫才有明確價值。
2. 想處理同義詞和講法差異，例如使用者說的食物名稱跟資料庫品名對不上。這是語意檢索可以補強的地方。

資料量成長到幾千筆以上，才會需要考慮換成 DynamoDB。換句話說，「更適合」取決於資料是什麼、規模多大，而不是託管服務一定比較好。

資料來源（AWS 官方公告與文件）：

• Amazon Bedrock Knowledge Bases
• Knowledge Bases 支援結構化資料檢索（2024/12）
• Amazon S3 Vectors 正式上線（2025/12）
• Knowledge Bases 支援 OpenSearch Managed Cluster（2025/03）

延伸四：讓產出更穩

Day29 提到，AI 產出的菜單很難完全控制。除了前面修過的候選池、驗證和 prompt，還有幾個方向可以試：

• 食物進來時就標好欄位（例如是否含咖啡因、是否油炸、是配菜還是點心），而不是執行時靠名稱關鍵字去猜。這是我 Day29 提過、還沒驗證的臆測。
• 候選篩選加上巨量營養素密度檢查，避免選到一份就佔很多份全穀雜糧的主餐。
• 實作蛋白質來源優先順序（豆、魚海鮮、蛋、禽肉、畜肉），目前只做了「油炸或加工食物排到後面」這個比較粗的排序。
• 建議範本庫：收錄幾則營養師寫的好範例，生成前先檢索最像的範例當格式參考。這其實也是一種 RAG，檢索到的不是營養數字，而是「範例寫法」。目前我是用食物分類加程式規則（主餐必選、再依偏好搭配附餐和飲料）來固定回答骨架，沒有驗證過範例庫會不會更好。

延伸五：營運面

• 補上 API 層的身份驗證和 Usage Plan 限制（Day28 提過的風險，目前只有被動的帳單警報）。
• 資料量長到「不想整包載入記憶體」時，把 S3 JSON 換成 DynamoDB（Day24 提過大概是幾千筆以上）。
• 申請調高 Lambda 併發額度，才能設定保留併發（Day28）。

小結

回到 Day1 那句話： 這個專案從一開始的動機，是想把營養師的專業判斷跟軟體工程結合，看看能玩出什麼新花樣。走完這一輪，在實作讓我體會到：跨領域不只是兩邊的知識都懂一點，而是在理解某個領域（domain）的同時，能清楚知道資訊領域有哪些工具可以解決問題、並且善用它們，同時也知道各種工具（包含 AI）的能耐和邊界。 例如這個專案裡，營養數字交給程式的固定公式、語言理解和挑選交給 AI、最後的專業判斷留給自己，這樣的分工，是在做這個專案的過程中一點一點摸索出來的。

但光知道怎麼分工還不夠，要把它做出來，還得熟悉手上的工具。例如：

• 自由文字的描述，要怎麼讓 AI 抽出重點、整理成固定的 JSON 格式（Day18）。
• 食物資料庫要怎麼設計，有哪些欄位、怎麼分類，才能讓 AI 在挑菜單時更符合預期（Day21）。
• prompt 該怎麼下，每個欄位要寫清楚目的和限制（Day17）。

這些細節，如果我不知道這些技術的存在，或不知道實作時要注意什麼，就不可能把腦中想要的產品做出來，要不就是產品吐出來的東西，一直達不到我想要的樣子。這有點像「工欲善其事，必先利其器」：領域知識決定我想做什麼，對工具的熟悉，決定我做不做得出來。這是一個滿有趣的過程。

總之呢~這系列文章終於告一段落了!! 謝謝閱讀到最後的你們!!